The following was waiting on top of more than one desk (on mine eventually ;-) - again causing undue delay. Please accept my apologies. Wilfried. ------------- Cut along the dotted line ----------------- Database Working Group Minutes of meeting, 28th January, 1998 at RIPE XXIX, Amsterdam, Kingdom of the Netherlands. (!!! => Action Point). The meeting began at 14:00. Wilfried Woeber chaired. 1. Administration. AMRM acted as scribe. JS sent unsolicited (but not unwelcome :-) ) notes to WW and AMRM after the meeting. CO agreed to become scribe while AMRM was swapped out to give a presentation. The proposed agenda, circulated previously, was agreed; no changes were made. The draft minutes of DB WG at RIPE 28 had been previously circulated. Comments were welcome on the mailing list. 2. The RIPE Database; an update on NCC activity. (A.M.R. Magee) Person & role data on the ftp site -> now controlled by an AUP => restricted access, still available on request, but based on an agreement with RIPE NCC, signed by a contact person. New release of the RIPE DB software v.2.1.1 available, runs on perl 5.004 RPSL -> report to Routing Wg DSTF (DB Sec Task Force)- > report to plenary Some bug fixes -> route object bug fixed New DB Code - design has begun - current functionality, new code - scalability - report from Maldwyn Morris later DB Consistency Project - State of the Database Reports -> report from the students later - Prevention -> new syntax checks; being implemented - Clean Up -> user education, new tools to be published State of DB reports - feedback welcome -> frequency, appearance, ..... Database Statistics - number of DB objects is doubling approximately every 8 - 10 months; - now 750K objects - number of DB updates slowly increasing, with major spikes every 6 - 8 months -> possibly TLD administrators doing a "clean-up" - number of DB queries gradually increasing, the growth is modulated by a short-term (~ 2 months) fluctuation now more than 2.2 x 10E6 queries per month ripe-dbm - mail bounces make the most mail -> new objects created in the DB -> these objects have a "notify" attribute which references an e-mail address which is not set up -> mail bounce to <ripe-dbm@ripe.net> - users are asking <ripe-dbm> for help before reading ripe-157 (AMRM swapped back into scribe). * DB consistency project; State of the DB Reports - WW introduced Kurt Dirnbauer and Horst Koenigshofer; he explained their role in the RIPE NCC as stagiares from the FS, Wiener Nieuwstadt. What is the DB consistency project ? Kurt Dirnbauer briefly described the RIPE Database Consistency Project, refering to the report written by students from the Vrij Universiteit van Amsterdam (and described by CO at the DB WG at RIPE 27). He said that the goal of this project is to remove the inconsistencies in the Database; e.g. make person references more reliable He pointed out that the RIPE DB is not a commercial DB; it is a "hand-built" database. This has advantages (e.g. portability) and disadvantages (not relational). He then showed an example of a State of the Database Report and a graph of one of the tables of data (using sample data). Technical Details Horst Koenigshofer then discussed the details of his program. This program takes the data and index files of the RIPE DB as input. It appends its output to existing files which contain the output from a previous run of the program. These files contain the numbers of each type of inconsistency. He said that at present, when there are 750K objects in the DB, that his program needs approx 4hrs on a PC (133 Mhz, 2 GB disc, 32MB RAM). Thus, his program will need 12 hours when there are 2 x 10E6 objects in the DB next year. Thus, improvements are planned: rewrite part of program and/or upgrade the hardware. Christian Halbe asked about the use of the output of the State of the DB reports. CO replied that reports to individual object managers would be available in the future. CO went on to say that clean-up tools for objects managers would be provided; the problem of who has the authority to change invalid objects would be addressed. Christian Halbe asked about plans to prevent further pollution of the RIPE Database. CO said that new syntax checks are defined; they will be implemented. WW asked whether the problems were because of structural inconsistencies or restricted modifications ??? Carsten Schiefner asked whether or not open access to the DB should be disallowed i.e. why should anyone with an e-mail address be able to create/update/delete objects ? WW replied ??? CO said that there existed an authorisation model for registering domain objects and IP address assignments; currently, a model is being developed for the Routing Registry. Thus, if all three models are in place, a general model for authorising DB updates could be deployed. WW pointed out that the modification of existing objects can be controlled and suggested that we make this mechanism more secure. There is already some control with the "mnt-lower" attribute. However, there is no control on the creation of person or role objects similar to the creation of a mntner object (which requires the manual intervention of the RIPE NCC). In the past, _everyone_ was welcome to register useful data in the RIPE DB. Should this change now ? * DB software Re-Engineering Maldwyn Morris, RIPE NCC discussed the existing code of the RIPE DB and outlined proposals for re-engineering it. He described the current system as one with well known interfaces, heavily used and "it works, but ....". He outlined the problems with the code: it is unspecified, undocumented, under commented, messy, and based on the functionality of perl4; i.e. the excellent new feature available in PERL5 are not used. He went on to say that the new version will be carefully planned: the code will be specified, documented and commented. API layers will be specified which will be coded in an appropriate language. External software (e.g. a database engine) will be used where appropriate. He described the workplan to develop this new software, but stressed that the existing functionality will be preserved; the goal here is not to introduce new functionality, but to make it easy to do so. AMRM pointed out that the software was specified in RIPE documents. MM replied that the functionality of the existing code was often different from the specification in the RIPE documents. Jake Khoun asked about goals for optimisation, e.g. increased speed. MM said that such improvements were under consideration. Jake Khoun suggested that Merit and RIPE NCC might combine appropriate pieces of DB software. Both he and MM agreed to continue the discussion off-line. CO stressed that this what was being dsicussed was new code with existing functionality; the RIPE NCC would continue to add new functionality to the existing code. WW commented that the existing code _is_ working and still performing satisfactorily. He himself would like to see a commercial database with the facility for shadow copies, ftp-copies etc. available all over Europe. He remarked how the NCC had reached the limit, in terms of volume, of the existing code. These limits are set by PERL and the operating system. It was pointed out that other organizations use similar code and link in external software. The NCC will consider this. * Other Developments !!! Jake Khuon and WW agreed to send a proposal for specifying new functionality to the RIDE mailing list. Jake indicated that the RIPE NCC code was used, but with a small modification to the process of handling as-macro objects. He went on to say that Cengiz had promised that the new version of the RA Toolset will support this. !!! Jake promised to send another pointer to the mailing list saying where the documents about this exist. CO remarked that the RIDE project had stopped, and with it a way to formulate the exchange of database information. Thus the IP registries are unable to exchange data. There is a major problem with the RIPE NCC being able to exchange data with ARIN; this problem may be solved at the level of an IETF WG or direct contact between IP registries. * Proposal for online registration of person objects (or role objects) to be done during a DNS domain registration (WW was swapped out of the chair to give a presentation on this topic; CO was swapped into the chair). The overall goal is to register a DNS domain. Currently there are two ways to do it, both are clumsy. The first method involves do some processes locally: e.g. rip apart the request for a domain and get the person object; then check if the person object is in the RIPE database. The new concept: do not mix DNS domain registration, and person/role registration. Start with person/role objects. Then submit domain object (or inetnum, or whatever), i.e. the referenced objects first, then the referencing objects. Currently, the only interface to the RIPE DB is based on e-mail. This is store and forward => slow (unreliable ?). The proposal on the table is to replace (or supplement ?) the e-mail interface with a process that will generate an new nic-hdl immediately. I.e. a separate communication path between update machine of the RIPE DB, and some application at the user side. So no disruption during the overall registration process occurs. This should include syntax checks and semantic checks (distributed, i.e. not only at the RIPE DB site, but also locally). There should at least be support for security, even if it is not implemented: - checks on the identity of the person sending in the update - responses should be signed - before anyone can use this path, they must first make a case to the RIPE NCC. WW felt that these three security checks were going to come anyway. WW presented this technical proposal and showed a sketch of the outline of the process. He pointed out that local checks could be implemented in the client. rough sketch: client local server DB master java-script <----> cgi bin <----> DB software local http tcp Most of the analysis done at the local side, additional testing done by the RIPE DB. WW said that some developement work had been done; a Java applet had been developed (for the client). Prototypes already exist, others are invited to also use it, if the community thinks that it is worthwhile. WW then asked the group for input ..... Christian Halbe said that this system was exactly what his organisation needed. They had a similar system, but it was based on e-mail and it was slow. Achim Patzner said that this system would be too late for his organisation. CO (as temporary Chair of the WG) thanked WW for his presentation. CO went on to say that some of the security issues mentioned earlier were being addresses by the DSTF (Database Security Task Force), including the definition of a secure database. CO invited input. Overall, there was support for this idea in order to develop a simple user interface. * Input from other WGs JS summarised the result of the Routing Work Group meeting, which was held earlier that day. In particular, JS mentioned: - authorisation: discussed both at the last IETF meeting and at the Routing Working Group that morning; updates should to the database should be authenticated; - more security: misuse/malicious use should be prevented - the Routing Registry is part of the overall registry; there is security on the IP numbers, but not on route objects. - more input for Database Working Group ?? * AOB none. * Close. RIPE XXIX DB WG Action Points ----------------------------- 1/. Jake Khuon and WW agreed to send a proposal for specifying new functionality to the RIDE mailing list. 2/. Jake promised to send another pointer to the mailing list saying where the documents about the RAToolset exist. ------------------------------------------------------